Subject: Changes to the DLUR specification - status & another update

From: "Ed Tremblay (254-5515)" <[email-masked]>
Date: Mon, 9 Aug 93 09:46:58 EDT

In my last note on this subject I listed 14 items as changes to the
DLUR document.  What follows is the status of those changes as well as
another new item:

1) 2) 3) 4) 5) 6) 7) 8) 9) 10) 11) have been incorporated into what
will be dlur2.ps when it is released.

12) Haven't received any comments so far - looks like I'll include the
    section as is.

13) The situations for returning a X'0806 0000' sense code will include
    not only receiving an encapsulated ACTPU which is missing a CV X'46'
    but also receiving an encapsulated ACTPU which includes an
    incomplete CV X'46' (e.g., missing its signalling information).

14) Here's a new case that came up Thursday; I'll include the change
    described in steps a) and b):

    In testing deactivation sequences a REQDISCONT was sent by a DSPU.
    The REQDISCONT was encapsulated by DLUR, and, when DLUS tried to
    process it, VTAM abended.  To cut down on abends (probably a worthy
    cause), I propose that DLUR, upon receiving a REQDISCONT from a
    DSPU,

      a) convert the REQDISCONT to a REQDACTPU, encapsulate it, and
         send it to DLUS on the CP-SVR pipe, and

      b) deactivate the DLC from the BF to the DSPU (emulating the
         receipt of a DISCONTACT)

    When I wrote section 5.6.3 (Abnormal SSCP-PU/SSCP-LU Session
    Deactivation (DLUR-Initiated)), I only considered how DLUR would
    handle DSPU outages (emulating INOPERATIVE cases in subarea BF
    processing).  Now we know of at least a second DLUR-initiated DSPU
    deactivation scenario.

    We also considered converting the REQDISCONT to a REQDACTPU at the
    DLUS; we didn't choose that alternative because in receiving the
    ensuing DACTPU from the DLUS, the DLUR would have no indication
    that it should also deactivate the DLC, which is what the REQDISCONT
    requested.

Ed Tremblay